Somewhere in your plant right now there is an OPC UA tunnel that a controls engineer set up two years ago to get vibration data to a reliability dashboard, and nobody remembers it exists. There’s a vendor VPN into the packaging line PLC that’s still active from a commissioning project. There’s a flat VLAN carrying HMI traffic, historian traffic, and now — because someone in IT finally got budget approval — an MES gateway pulling tags for a Unified Namespace. None of this was designed. It accumulated. And the MES project is the first time anyone has been forced to look at it directly.
That’s actually the good news. MES and UNS integration work is dragging OT network architecture out of the shadows faster than any compliance audit ever did, because you cannot build a reliable data pipeline on top of a network nobody can diagram. The bad news is that most teams are handling this backwards. They treat the MES gateway or historian as a bolt-on device sitting wherever there’s a free switch port, then worry about segmentation later, if at all. IEC 62443-3-2 says to do the opposite: define your zones and conduits first, based on risk, and let the connectivity follow the architecture. For a brownfield retrofit, “first” isn’t realistic. But “deliberate, before you cut anything” is — and that’s the method worth following.
Why the MES gateway deserves its own zone, not a spot on an existing one
The instinct in a lot of plants is to land the MES/UNS gateway inside whatever zone already handles data collection — usually wherever the historian lives, or worse, on the same segment as HMIs and engineering workstations. That instinct is understandable and wrong. The MES gateway is a fundamentally different kind of asset than anything else on the plant floor: it’s designed to talk outward, to IT-facing systems, cloud brokers, MQTT infrastructure, sometimes directly to AI agents or analytics platforms consuming a Sparkplug B or OPC UA PubSub feed. That outward-facing posture is precisely the risk profile IEC 62443 zoning exists to isolate.
A zone, per the standard, is a grouping of assets that share common security requirements. A conduit is the communication path between zones, and it’s supposed to carry a defined, restricted set of traffic with its own security controls — not just “whatever needs to get through today.” When you drop an MES gateway into your existing Level 2/Level 3 zone without re-evaluating the boundary, you’ve quietly raised the risk profile of every PLC and HMI in that zone to match the gateway’s, because now they’re all reachable through whatever compromises the gateway. The gateway should sit in its own zone, with a purpose-built conduit into the process zones below it and another into the IT/enterprise zone above it. That’s not bureaucratic overhead — it’s the entire point of segmentation.
Step one: inventory the conduits you already have, informally
Before you draw a single new boundary, find out what already crosses the ones you assume exist. This is the step teams skip, and it’s the one that causes incidents later. Walk the network with intent to find:
- OPC UA client/server tunnels set up for point solutions — a dashboard, a condition-monitoring tool, a data science pilot that never got decommissioned.
- Vendor remote access paths: VPN concentrators, jump boxes, or remote support tools (AnyDesk-style or vendor-proprietary) left active after commissioning or the last service call.
- Firewall rules that were opened for a specific project and never closed, especially anything with a broad source range or “any” in the destination port field.
- Historian-to-historian or historian-to-cloud replication jobs that quietly bridge zones nobody thought of as connected.
Document each of these as a conduit, even though none of them were designed as one. This is your real attack surface, not the tidy Purdue-model diagram sitting in a binder from the original system integration project. Most plants are surprised by how many of these informal conduits exist and how few have any monitoring or logging attached to them at all.
Step two: assign SL-T honestly, then face the SL-A gap
IEC 62443 asks you to assign a target security level (SL-T) to each zone based on the consequence of compromise, then assess the achieved level (SL-A) of what’s actually in place. The honest version of this exercise, for most brownfield plants, produces an uncomfortable gap. A zone containing safety-instrumented systems or a line that can’t tolerate downtime probably warrants an SL-T of 3. The achieved level, once you account for flat switching, shared credentials on engineering workstations, and unmonitored vendor access, is often closer to 1.
Don’t round that gap away to make the project look manageable. The gap is the point — it tells you where conduit controls need to go first. A zone with a wide SL-T/SL-A gap and high consequence of compromise (a line feeding a safety system, a utility system, anything with physical consequence) gets prioritized ahead of a zone where the gap exists but the blast radius is a quality dashboard going stale for an hour. This is also where you’ll have the hardest conversations with plant management, because closing an SL-T/SL-A gap on a zone with safety systems in it is not a “someday” project, and the MES rollout is a legitimate forcing function to get that conversation on the calendar.
Sequencing the cut without stopping the line
The practical fear driving avoidance of this work is simple: nobody wants to be the person who took down a production line by rerouting a network. That fear is legitimate, and it’s manageable with the right sequence.
- Map before you touch anything. Passive network monitoring for a defined period — long enough to catch weekly and monthly batch cycles, shift changeovers, and maintenance windows — will surface traffic patterns that a point-in-time audit misses.
- Build the new MES zone in parallel, not in place. Stand up the gateway and its conduit on new switching or a new VLAN alongside the existing flat network, rather than carving the existing network apart first. Migrate traffic to it deliberately.
- Use firewalls or Layer 3 switches as the conduit enforcement point, and start in monitor mode. Deploy the rule set, log what it would have blocked, review it against known-good traffic, then flip to enforcement. This catches the informal conduit you forgot about before it catches you.
- Segment the zones with the worst SL-T/SL-A gap and the least production risk first. Build organizational confidence and process muscle on lower-stakes boundaries before tackling the zone with the safety system in it.
- Schedule the highest-risk cuts inside an actual maintenance window, with rollback fully planned, not improvised. A conduit change on a zone touching continuous production is not a Tuesday-afternoon change ticket.
The part nobody wants to hear
This work is not a one-time project that ends when the MES go-live happens. Zones and conduits drift the same way the original flat network drifted — one exception, one vendor request, one “just for now” firewall rule at a time. The difference this time is that you’ll actually have a diagram, a documented SL-T for each zone, and a conduit inventory to check drift against. That’s the real deliverable of doing this properly during the MES retrofit: not a compliance checkbox, but a network you can reason about the next time someone asks to open a new path into it — which, given where MES, UNS, and AI-agent integration are headed, is going to be soon.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
